3장. LLM은 어떻게 답변을 만드는가

1. LLM은 사람처럼 생각하는 걸까?

ChatGPT 같은 AI를 사용하다 보면 정말 사람이 생각해서 답하는 것처럼 느껴질 때가 있다.

질문을 이해하는 것 같고, 문맥도 기억하는 것 같고, 코드도 작성하고, 긴 문서도 요약한다.

그래서 처음에는 이런 생각이 들 수 있다.

“AI가 진짜로 내용을 이해하고 생각하는 건가?”

하지만 LLM은 사람처럼 의식이나 감정을 가지고 생각하는 존재는 아니다.

LLM은 입력된 문장을 바탕으로 다음에 올 가능성이 높은 내용을 예측하면서 답변을 만들어낸다.

예를 들어 다음 문장을 보자.

오늘 점심에는 김치찌개를 먹고,
저녁에는 된장찌개를

이 문장 다음에는 “먹었다”, “먹을 예정이다”, “끓였다” 같은 표현이 올 가능성이 높다.

LLM은 이와 비슷한 방식으로 문맥을 보고 다음에 올 단어를 예측한다.

다만 실제 LLM은 단순히 바로 다음 단어 하나만 보는 수준이 아니다.
훨씬 더 긴 문맥을 참고하고, 문장 구조, 질문 의도, 코드 패턴, 대화 흐름 등을 함께 고려한다.

그래서 겉으로 보기에는 사람이 이해하고 답변하는 것처럼 보인다.

하지만 개발자 입장에서는 이렇게 이해하는 것이 좋다.

LLM은 사람처럼 생각한다기보다,
많은 데이터를 바탕으로 문맥상 그럴듯한 답변을 생성하는 모델이다.

이 관점이 중요하다.

LLM이 항상 정답을 말하는 것이 아니라, 그럴듯한 답변을 생성하는 모델이라는 점을 이해해야 한다.
그래야 AI 답변을 사용할 때 검증이 필요하다는 사실도 자연스럽게 받아들일 수 있다.

LLM은 Large Language Model의 약자다.
대규모 텍스트와 코드 데이터를 학습해 문장을 이해하고 생성하는 데 특화된 AI 모델이다.

2. LLM은 문장을 토큰 단위로 처리한다

사람은 문장을 단어와 의미 중심으로 읽는다.

예를 들어 다음 문장을 보자.

개발자는 AI를 도구로 사용할 수 있다.

사람은 이 문장을 자연스럽게 하나의 문장으로 이해한다.

하지만 LLM은 문장을 그대로 읽는 것이 아니라, 더 작은 단위로 쪼개서 처리한다.
이때 사용하는 단위를 토큰이라고 한다.

토큰은 단어와 비슷하지만 완전히 같지는 않다.

예를 들어 영어 문장에서는 단어 단위와 비슷하게 나뉘는 경우가 많다.

I like cloud computing.

대략 다음처럼 나뉠 수 있다.

I / like / cloud / computing / .

하지만 한국어는 조사, 어미, 복합어가 많기 때문에 조금 더 다르게 쪼개질 수 있다.

개발자는 AI를 도구로 사용할 수 있다.

이 문장은 모델에 따라 다음처럼 나뉠 수 있다.

개발 / 자는 / AI / 를 / 도구 / 로 / 사용 / 할 / 수 / 있다 / .

실제 토큰 분리는 모델마다 다르다.
중요한 것은 LLM이 문장을 내부적으로 토큰 단위로 처리한다는 점이다.

토큰은 AI 서비스에서 매우 중요하다.

왜냐하면 대부분의 AI API 비용은 토큰 수를 기준으로 계산되기 때문이다.

입력 토큰:
사용자가 AI에게 보낸 질문, 문서, 코드

출력 토큰:
AI가 생성한 답변

예를 들어 긴 문서를 AI에게 넣고 요약을 요청하면 입력 토큰이 많아진다.
AI가 긴 답변을 생성하면 출력 토큰도 많아진다.

즉, AI를 서비스에 붙일 때는 질문과 답변이 길어질수록 비용도 증가한다.

토큰은 AI가 문장을 처리하는 기본 단위다.
단어와 비슷하지만 모델에 따라 쪼개지는 방식이 다르며, AI 비용과 처리 가능한 문맥 길이에 영향을 준다.

3. LLM은 다음 토큰을 예측하면서 답변을 만든다

LLM의 답변 생성 방식을 아주 단순화하면 다음과 같다.

지금까지의 문맥을 보고
→ 다음에 올 가능성이 높은 토큰을 선택하고
→ 다시 그다음 토큰을 선택하고
→ 이 과정을 반복해 문장을 만든다

예를 들어 사용자가 이렇게 질문했다고 해보자.

REST API에서 GET과 POST의 차이를 설명해줘.

LLM은 이 질문을 보고 답변의 첫 부분을 만들기 시작한다.

GET은

그다음에는 “서버에서”, “데이터를”, “조회할”, “때” 같은 토큰이 이어질 가능성이 높다.

그래서 답변은 이런 식으로 생성된다.

GET은 서버에서 데이터를 조회할 때 주로 사용하고,
POST는 서버에 데이터를 생성하거나 전달할 때 주로 사용합니다.

이 과정은 사람에게는 한 번에 문장을 작성하는 것처럼 보인다.
하지만 내부적으로는 토큰을 하나씩 이어 붙이며 생성하는 방식에 가깝다.

코드도 마찬가지다.

사용자가 이렇게 요청했다고 해보자.

JavaScript로 두 숫자를 더하는 함수를 만들어줘.

LLM은 코드 패턴을 바탕으로 다음과 같은 결과를 생성할 수 있다.

function add(a, b) {
    return a + b;
}

이 결과도 “함수를 진짜로 이해해서 작성했다”기보다는, 학습한 코드 패턴과 현재 요청 문맥을 바탕으로 가장 적절해 보이는 토큰들을 이어 붙인 결과다.

물론 이 설명만 들으면 LLM이 단순 자동완성처럼 느껴질 수 있다.

하지만 실제 LLM은 매우 큰 규모의 데이터와 복잡한 모델 구조를 사용한다.
그래서 단순 자동완성과는 비교하기 어려울 정도로 높은 수준의 문맥 이해와 생성 능력을 보여준다.

다만 핵심은 같다.

LLM은 답을 데이터베이스에서 꺼내오는 것이 아니다.
문맥을 바탕으로 새로운 답변을 생성한다.

이 때문에 같은 질문을 해도 매번 조금씩 다른 답변이 나올 수 있다.

4. 같은 질문에도 답변이 달라지는 이유

AI에게 같은 질문을 여러 번 했는데 답변이 조금씩 달라지는 것을 본 적이 있을 것이다.

예를 들어 이렇게 물어본다.

좋은 API 설계 원칙을 알려줘.

한 번은 RESTful 설계를 중심으로 답할 수 있고,
다른 한 번은 보안, 확장성, 문서화까지 포함해서 답할 수 있다.

이유는 LLM이 정해진 답변을 그대로 꺼내오는 방식이 아니기 때문이다.

LLM은 가능한 여러 후보 중에서 다음 토큰을 선택하면서 답변을 만든다.
이때 어떤 후보를 얼마나 다양하게 선택할지에 영향을 주는 설정이 있다.

대표적인 것이 temperature다.

temperature가 낮으면 더 안정적이고 예측 가능한 답변을 만든다.
temperature가 높으면 더 다양하고 창의적인 답변을 만들 가능성이 커진다.

예를 들어 다음과 같이 생각할 수 있다.

temperature 낮음:
정리, 요약, 코드 생성, 공식 문서 스타일 답변에 적합

temperature 높음:
아이디어 발산, 카피라이팅, 창의적인 문구 생성에 적합

개발 업무에서는 보통 너무 높은 temperature를 사용하지 않는 것이 좋다.

특히 코드 생성, SQL 생성, 설정 파일 생성처럼 정확성이 중요한 작업에서는 안정적인 답변이 더 중요하다.

반대로 마케팅 문구, 서비스명 후보, 기획 아이디어처럼 다양한 후보가 필요한 작업에서는 조금 높은 temperature가 도움이 될 수 있다.

temperature는 AI 답변의 다양성을 조절하는 설정값이다.
낮을수록 안정적이고 비슷한 답변을 만들고, 높을수록 다양한 표현과 아이디어가 나올 가능성이 커진다.

5. LLM은 문맥을 보고 답한다

LLM이 강력한 이유 중 하나는 앞뒤 문맥을 함께 볼 수 있다는 점이다.

예를 들어 사용자가 이렇게 질문했다고 해보자.

이 코드에서 문제점 찾아줘.

이 말만으로는 AI가 제대로 답하기 어렵다.

어떤 코드인지 모르기 때문이다.

하지만 코드와 함께 질문하면 상황이 달라진다.

function divide(a, b) {
    return a / b;
}

이 코드에서 문제점 찾아줘.

이제 AI는 코드라는 문맥을 보고 답할 수 있다.

b가 0일 때 Infinity가 반환될 수 있으므로,
0으로 나누는 경우를 예외 처리하는 것이 좋습니다.

문맥이 많아질수록 AI는 더 구체적인 답변을 할 수 있다.

예를 들어 단순히 코드만 주는 것보다, 이 코드가 어떤 상황에서 사용되는지도 알려주면 더 좋은 답을 얻을 수 있다.

이 함수는 결제 금액을 포인트로 나누는 계산에 사용돼.
b가 0이거나 null일 수 있는 상황도 있어.
운영 환경에서 안전하게 사용할 수 있도록 수정해줘.

이렇게 질문하면 AI는 단순히 0 나누기만 보는 것이 아니라, 운영 환경에서 필요한 예외 처리까지 고려할 가능성이 높아진다.

즉, LLM에게 좋은 답을 받으려면 충분한 문맥을 제공해야 한다.

나쁜 요청:
이 코드 고쳐줘.

좋은 요청:
이 코드는 결제 승인 콜백에서 사용하는 코드야.
중복 콜백이 들어올 수 있고, 이미 처리된 주문은 다시 승인되면 안 돼.
현재 코드에서 중복 처리 문제가 있는지 봐줘.

AI가 똑똑하다고 해도, 사용자가 제공하지 않은 정보를 완벽히 알 수는 없다.

그래서 AI를 잘 쓰려면 질문 자체보다 문맥을 잘 주는 능력이 중요하다.

문맥은 AI가 답변을 만들 때 참고하는 주변 정보다.
질문뿐 아니라 코드, 오류 메시지, 목적, 제약사항, 현재 상황 등이 모두 문맥이 될 수 있다.

6. 컨텍스트 윈도우는 AI가 한 번에 볼 수 있는 범위다

LLM이 문맥을 본다고 해서 무한히 많은 내용을 기억할 수 있는 것은 아니다.

AI가 한 번에 참고할 수 있는 입력 범위를 컨텍스트 윈도우라고 한다.

쉽게 말하면 AI가 현재 대화에서 펼쳐놓고 볼 수 있는 작업 공간이다.

예를 들어 컨텍스트 윈도우가 작으면 긴 문서 전체를 한 번에 넣기 어렵다.
반대로 컨텍스트 윈도우가 크면 더 긴 문서, 더 많은 코드, 더 긴 대화 내용을 함께 참고할 수 있다.

컨텍스트 윈도우가 작을 때:
짧은 질문과 짧은 코드 중심으로 처리 가능

컨텍스트 윈도우가 클 때:
긴 문서, 여러 파일, 긴 대화 흐름까지 참고 가능

하지만 컨텍스트 윈도우가 크다고 해서 항상 좋은 것은 아니다.

긴 내용을 많이 넣으면 비용이 증가한다.
또 너무 많은 정보를 넣으면 AI가 중요한 내용을 놓칠 수도 있다.

예를 들어 에러 하나를 해결하려고 하는데 프로젝트 전체 코드를 모두 넣는 것은 좋은 방법이 아닐 수 있다.

오히려 필요한 정보만 정리해서 주는 편이 더 좋다.

좋은 문맥 제공 방식:
- 문제가 발생한 코드
- 에러 메시지
- 기대한 동작
- 실제 동작
- 실행 환경
- 최근 변경 사항

AI에게 정보를 많이 주는 것보다, 관련 있는 정보를 잘 골라서 주는 것이 중요하다.

컨텍스트 윈도우는 AI가 한 번에 참고할 수 있는 문맥의 최대 범위다.
범위가 클수록 긴 내용을 처리할 수 있지만, 비용과 정확성 측면에서 필요한 정보만 넣는 설계가 중요하다.

7. LLM은 학습한 지식과 입력된 문맥을 함께 사용한다

LLM은 사전에 많은 데이터를 학습한다.

이 과정에서 언어, 코드, 문서 구조, 일반 지식, 프로그래밍 패턴 등을 익힌다.

그래서 사용자가 별도 설명을 하지 않아도 다음과 같은 질문에 답할 수 있다.

HTTP 상태 코드 404는 무슨 의미야?

JavaScript에서 Promise는 왜 사용해?

SQL Injection이 위험한 이유를 알려줘.

이런 질문은 모델이 학습한 일반 지식을 바탕으로 답할 수 있다.

하지만 회사 내부 정보는 다르다.

예를 들어 다음과 같은 질문은 AI가 알 수 없다.

우리 회사의 방송 시작 API는 어떤 흐름으로 동작해?

지난주 장애의 정확한 원인이 뭐였어?

우리 서비스에서 VIP 회원 등급 기준은 어떻게 돼?

AI가 이 질문에 답하려면 내부 문서, 코드, 로그, 회의록 같은 정보가 필요하다.

이때 사용하는 방식이 나중에 배울 RAG다.

RAG는 AI가 모르는 외부 정보를 검색해서, 그 내용을 바탕으로 답변하게 만드는 구조다.

사용자 질문
→ 관련 문서 검색
→ 검색된 내용을 AI에게 전달
→ AI가 문서를 근거로 답변 생성

즉, LLM은 기본적으로 학습한 지식으로 답하지만,
필요할 때 외부 문맥을 넣어주면 회사 내부 정보나 최신 정보도 다룰 수 있다.

RAG는 Retrieval-Augmented Generation의 약자다.
AI가 자체 지식만으로 답하지 않고, 외부 문서나 DB에서 관련 정보를 검색한 뒤 답변하도록 만드는 방식이다.

8. LLM이 틀린 답을 할 수 있는 이유

LLM은 매우 똑똑해 보이지만 틀릴 수 있다.

이유는 LLM이 “정답 데이터베이스”가 아니기 때문이다.

LLM은 문맥상 가장 그럴듯한 답변을 생성한다.
그 과정에서 사실이 아닌 내용을 자연스럽게 말할 수 있다.

이런 현상을 환각이라고 한다.

예를 들어 다음과 같은 일이 생길 수 있다.

- 존재하지 않는 라이브러리 함수를 있다고 설명한다.
- 오래된 API 사용법을 최신 방식처럼 알려준다.
- 실제로는 없는 공식 문서 링크를 만들어낸다.
- 보안상 위험한 코드를 안전하다고 말한다.
- 회사 내부 정책을 모르는 상태에서 추측해 답한다.

개발자에게 특히 위험한 것은 코드 관련 환각이다.

예를 들어 AI가 어떤 프레임워크에 존재하지 않는 옵션을 제안할 수 있다.

app.use(express.secureMode(true));

이 코드가 그럴듯해 보일 수 있지만, 실제 Express에는 이런 옵션이 없다.

또는 SQL 최적화를 제안하면서 실제 DB 버전에서는 지원하지 않는 문법을 사용할 수도 있다.

그래서 AI가 만든 코드는 반드시 실행해보고 검증해야 한다.

AI 답변 검증 체크:
- 실제로 실행되는가?
- 공식 문서와 맞는가?
- 현재 사용하는 버전에서 지원되는가?
- 보안 문제가 없는가?
- 예외 상황을 처리하는가?

AI의 답변이 자연스럽다고 해서 맞는 것은 아니다.
자연스러운 문장과 정확한 사실은 다르다.

환각은 AI가 사실이 아닌 내용을 그럴듯하게 만들어내는 현상이다.
개발에서는 존재하지 않는 함수, 잘못된 설정, 틀린 문법, 가짜 출처 등으로 나타날 수 있다.

9. LLM은 확률적이지만 실무에서는 통제할 수 있다

LLM은 확률적으로 답변을 생성한다.

그래서 같은 질문에도 조금씩 다른 답이 나올 수 있고, 가끔은 예상과 다른 형식으로 답할 수 있다.

하지만 그렇다고 실무에 사용할 수 없는 것은 아니다.

개발자는 여러 방법으로 AI의 출력을 통제할 수 있다.

첫 번째는 출력 형식을 명확히 지정하는 것이다.

아래 형식으로만 답변해줘.

- 원인:
- 영향:
- 해결 방법:
- 주의사항:

두 번째는 JSON 형식으로 응답하게 하는 것이다.

다음 형식의 JSON으로만 응답해줘.

{
  "summary": "요약 내용",
  "riskLevel": "low | medium | high",
  "issues": [
    {
      "title": "문제 제목",
      "description": "설명",
      "suggestion": "개선 방법"
    }
  ]
}

세 번째는 예시를 함께 주는 것이다.

다음 예시와 같은 스타일로 답변해줘.

예시:
입력: 결제 콜백이 두 번 들어옴
출력:
- 원인: PG사 재시도 또는 네트워크 지연 가능성
- 대응: 주문 상태를 먼저 확인하고 이미 처리된 주문은 무시

네 번째는 AI 응답을 코드에서 한 번 더 검증하는 것이다.

예를 들어 AI가 JSON을 반환하더라도, 서버에서는 반드시 파싱과 스키마 검증을 해야 한다.

AI 응답
→ JSON 파싱
→ 필수 필드 확인
→ 값 범위 확인
→ 비정상 응답이면 재요청 또는 실패 처리

AI는 자유롭게 문장을 생성하는 데 강하지만, 서비스에서는 예측 가능한 출력이 필요하다.

그래서 실무에서는 프롬프트 설계와 응답 검증을 함께 사용해야 한다.

JSON은 데이터를 주고받기 위한 대표적인 형식이다.
AI 응답을 JSON으로 받으면 서버에서 결과를 파싱하고 저장하거나 후속 로직에 연결하기 쉽다.

10. LLM을 개발 업무에 사용할 때의 기본 원칙

LLM을 개발 업무에 사용할 때는 몇 가지 원칙을 지키는 것이 좋다.

10.1 AI에게 충분한 맥락을 제공한다

AI는 사용자가 제공한 정보 안에서 더 좋은 답을 만든다.

단순히 “이거 왜 안 돼?”라고 묻기보다, 다음 정보를 함께 주는 것이 좋다.

- 무엇을 하려고 했는지
- 어떤 코드인지
- 어떤 에러가 발생했는지
- 기대한 결과는 무엇인지
- 실제 결과는 무엇인지
- 실행 환경은 무엇인지

예를 들어 나쁜 질문은 다음과 같다.

이거 왜 에러나?

좋은 질문은 다음과 같다.

Node.js 20 환경에서 Express 서버를 실행 중이야.

아래 코드는 로그인 API이고,
요청 시 "Cannot read properties of undefined" 에러가 발생해.

기대한 동작은 req.body.email 값을 읽는 것이고,
실제 동작은 req.body가 undefined로 나와.

원인과 수정 방법을 설명해줘.

10.2 AI 답변은 초안으로 본다

AI가 만든 답변은 매우 유용하지만, 그대로 정답이라고 보면 안 된다.

특히 다음 결과는 반드시 검증해야 한다.

- 운영 코드
- SQL
- 보안 설정
- 인프라 설정
- 개인정보 처리 로직
- 결제 로직
- 인증/권한 로직

AI는 빠른 초안을 만드는 데 강하다.
개발자는 그 초안을 검토하고 실제 서비스 수준으로 끌어올려야 한다.

10.3 중요한 내용은 공식 문서와 테스트로 확인한다

AI가 어떤 라이브러리 사용법을 알려줬다면 공식 문서와 맞는지 확인해야 한다.

특히 버전에 따라 사용법이 달라지는 경우가 많다.

확인해야 할 것:
- 현재 사용하는 라이브러리 버전
- 공식 문서의 최신 사용법
- deprecated 여부
- 보안 권장 설정
- 실제 실행 테스트 결과

AI가 자신 있게 말해도 틀릴 수 있다.

실무에서는 AI의 자신감보다 실행 결과와 공식 문서가 더 중요하다.

deprecated는 더 이상 사용을 권장하지 않는 기능을 의미한다.
당장은 동작할 수 있지만, 향후 제거되거나 보안·호환성 문제가 생길 수 있다.

10.4 민감 정보는 함부로 입력하지 않는다

AI에게 질문할 때 회사 내부 코드, 로그, 개인정보, 인증키를 그대로 넣는 것은 위험할 수 있다.

특히 외부 클라우드 AI를 사용할 때는 더 조심해야 한다.

AI에게 넣으면 위험한 정보:
- 사용자 개인정보
- 비밀번호
- API Key
- Access Token
- DB 접속 정보
- 내부망 주소
- 결제 정보
- 미공개 사업 정보

필요하다면 민감 정보를 마스킹해서 넣어야 한다.

나쁜 예:
user_email = "real-user@example.com"
api_key = "sk_live_xxxxxxxxx"

좋은 예:
user_email = "[USER_EMAIL]"
api_key = "[API_KEY]"

AI를 잘 쓰는 것만큼 안전하게 쓰는 것도 중요하다.

11. LLM을 이해하면 AI를 더 잘 사용할 수 있다

LLM의 내부 구조를 모두 수학적으로 이해할 필요는 없다.

하지만 개발자는 최소한 다음 정도는 알고 있어야 한다.

- LLM은 토큰 단위로 문장을 처리한다.
- LLM은 다음 토큰을 예측하면서 답변을 생성한다.
- LLM은 입력된 문맥에 큰 영향을 받는다.
- LLM은 한 번에 볼 수 있는 문맥 범위가 제한되어 있다.
- LLM은 학습한 지식과 사용자가 제공한 정보를 함께 사용한다.
- LLM은 그럴듯하게 틀릴 수 있다.
- LLM의 출력은 프롬프트와 검증 로직으로 어느 정도 통제할 수 있다.

이 개념을 알면 AI를 사용할 때 막연한 기대를 줄일 수 있다.

AI가 왜 좋은 답을 했는지,
왜 엉뚱한 답을 했는지,
어떻게 질문을 바꿔야 하는지,
어떤 결과를 반드시 검증해야 하는지 판단할 수 있다.

AI를 마법처럼 보면 실무에 적용하기 어렵다.
하지만 AI를 특성이 있는 도구로 이해하면 훨씬 안전하고 효과적으로 사용할 수 있다.

12. 정리

LLM은 사람처럼 생각하는 존재가 아니다.

LLM은 대규모 텍스트와 코드 데이터를 학습하고, 입력된 문맥을 바탕으로 다음에 올 가능성이 높은 토큰을 생성하면서 답변을 만든다.

그래서 질문에 답하고, 코드를 작성하고, 문서를 요약하고, 오류를 분석할 수 있다.

하지만 LLM은 정답 데이터베이스가 아니다.

모르는 내용을 추측할 수 있고, 존재하지 않는 함수나 설정을 만들어낼 수도 있다.
그래서 개발자는 AI 답변을 그대로 믿지 말고 반드시 검증해야 한다.

LLM을 잘 사용하려면 좋은 문맥을 제공해야 한다.
필요한 정보를 충분히 주고, 원하는 출력 형식을 명확히 하고, 중요한 결과는 테스트와 공식 문서로 확인해야 한다.

이 장에서 기억해야 할 핵심은 하나다.

LLM은 답을 “찾는” 도구가 아니라, 문맥을 바탕으로 답을 “생성하는” 도구다.

이 차이를 이해하면 AI를 훨씬 더 현실적으로 사용할 수 있다.

3장 핵심 요약